fix(integrity): --lock update must regenerate on corrupt lockfile#515
Conversation
`updateLockFile` early-returned whenever `checkLockFileLight` passed, i.e. whenever `mopsTomlDepsHash` matched. That light check does not validate the per-file hashes in `mops.lock`, so a lockfile with a corrupt file-level hash (e.g. one written by a pre-2.12.2 CLI, a partial/crashed write, or a manual edit) could never be repaired via `mops install --lock update`: the update no-op'd, the follow-up `checkLockFile` then failed on the same corrupt hash and exited 1. The only recovery was `rm mops.lock`. Thread the existing `force` flag from `checkIntegrity` into `updateLockFile`. When the user explicitly passes `--lock update`, skip the light-check shortcut and unconditionally regenerate. Default `mops install` (no flag) still hits the fast path. Add a regression test that corrupts one per-file hash and asserts `install --lock update` rewrites the lock to a non-corrupt state. Fixes caffeinelabs#514.
|
An independent TS-savvy review flagged one framing question worth surfacing for discussion, @Kamirus: Narrow fix vs. widening
|
… fails When `checkLockFile` exits on a per-file hash mismatch, point users at the now-working `--lock update` recovery flag. Without this hint, users hitting caffeinelabs#514 had no in-product signal that the escape hatch existed. Also document the recovery use case in `mops install --lock` docs. Made-with: Cursor
2 participants
Fixes #514.
What changes for users
mops install --lock updatenow reliably regeneratesmops.lockeven when the existing lockfile has a stale or corrupt per-file hash. Previously this case silently no-op'd and then exited 1 on the follow-up integrity check, so--lock updatecould not recover a broken lock — the only escape hatch wasrm mops.lock. That hatch is no longer required.Default
mops install(no flag) is unchanged; the fast-path shortcut still fires when the lockfile'smopsTomlDepsHashmatches.Root cause
updateLockFileshort-circuits viacheckLockFileLight, which only validatesmopsTomlDepsHash. When mops.toml hasn't changed but the lockfile's per-filehashesblock is corrupt, the shortcut fires → nothing is rewritten → the subsequentcheckLockFile(force)finds the same corrupt hash and callsprocess.exit(1). Users get "Integrity check failed" with no way out except manual deletion ofmops.lock.Fix
Thread the existing
forceboolean fromcheckIntegrityintoupdateLockFile.force = !!lockis already true exactly when the user explicitly passed--lock update, so:mops install(no flag, outside CI) →force = false, keeps the fast-pathmops install --lock update→force = true, bypasses the light-check shortcut, always regeneratesmops install --lock check/--lock ignore→ unchangedTest plan
Added a regression test (
--lock update rewrites a lockfile with a corrupt file hash) that:mops installto produce a valid lockfile.mops install --lock update.Verified reverting the fix (restoring
updateLockFile()/if (checkLockFileLight()) return) makes the new Jest test fail with the expected "Integrity check failed" / "Mismatched hash" error.Related
--lock updateable to heal locks that were already written in the corrupt state.